Workflow management is a rapidly evolving technology that many businesses in a variety of industries utilize to handle business processes. A business process, as defined by the Workflow standard—Terminology & glossary, Technical Report WFMC-TC-1011, Worflow Management Coalition, June 1996. Versions 2.0., is simply a set of one or more linked activities that collectively realize a business objective or a policy goal, typically within the context of an organizational structure defining functional roles and relationships. A workflow is defined as the automation of a business process, in whole or in part, during which documents, information, or activities are passed from one participant to another, according to a set of predefined rules. A workflow management system (WfMS) defines, creates, and manages the execution of workflows.
Examples of workflow software include BusinessWare software, available from Vitria Technology, Inc. of Sunnyvale, Calif., Inconcert software, available from TIBCO Software, Inc. of Palo Alto, Calif., MQ Series software, available from International Business Machines Corporation (IBM), of Armonk, N.Y., and Staffware 2000, available from Staffware of Berkshire, United Kingdom.
There are hundreds of commercial workflow management systems (WfMSs), which are available on the market, as well as many research prototypes. While each system has a different process model, most of them share the same basic concepts. In one example, a process is described by a directed graph that has four different kinds of nodes.
Work nodes (also called service nodes) represent the invocation of activities (also called services), which are assigned for execution to a human or automated resource. Route nodes are decision points that route the execution flow among nodes based on an associated routing rule. Start nodes denote the entry point to the process. Typically, only one start node is allowed in a process. Complete nodes denote termination points.
There are many business processes in which an activity needs to be executed multiple times in parallel. For example, a restaurant brokering service may need to request the rates and availability from several restaurants that provide on-line access to this type of information. The request node that requests rates and availability may need to be repeated for all the restaurants that meet a particular criteria (e.g., in a particular vicinity).
In some of these applications, the exact number of activations for the node is known at the time when the process definition is created. For example, in a small town, the number of restaurants may be relatively static. However, there are other applications where the exact number of parallel activations is not known at the time when the process definition is generated. For example, in a large metropolitan area, the number of restaurants may vary widely since many restaurants may open for business or close for business on any given day.
To model such a business process with traditional process models, the process developer is required to employ very complex process definitions to attempt to account for all the possible cases. For example, the developer may “guess” a maximum number of parallel activities that need to be activated in executions of the business process. In the example above, a process developer may assume that there will be at most twenty (20) restaurants. The developer then models a corresponding number of nodes in the workflow definition. FIG. 7 illustrates an exemplary process definition that has a request node for each of the twenty restaurants. Unfortunately, these complex process definitions are difficult to specify and even more difficult to maintain. Furthermore, this approach is limited since when there are more restaurants than the assumed maximum number (e.g., a number greater than twenty in this case), there is no provision in the process definition to handle such a case.
Some prior art approaches allow the multiple activation of services for each node, where the number of instances is based on the number of available resources. The Process Manager product available from Hewlett-Packard (HP) of Palo Alto, Calif., the assignee of the present invention, is an example of such an approach. In this approach, multiple activities can be executed in parallel within a work node. However, it is noted that the number of activities that are executed in parallel is always equal to the number of resources that are available for execution of that activity. In other words, no other criteria for the selection of the number of parallel activations are possible.
Furthermore, each activity is assigned to a different resource. Also, all the activities have the same input data. Moreover, the attributes of the node (e.g., the service selection, resource selection, security, exception handling specification) are the same for every activity execution within the work node. As can be appreciated, such a solution lacks flexibility. In fact, it would instead be desirable to have different resource selection criteria, different data, and different security and exception handling criteria depending on the purpose of the activity execution.
Consequently, it would be desirable to have a mechanism that allows for multiple executions, where the input can be varied for each execution, and the attributes of the execution can be varied for each execution, thereby providing a flexible solution.
Based on the foregoing, there remains a need for a multinode method and system having activation rules and termination rules that overcomes the disadvantages set forth previously.